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NASTRAN COMPUTER RESOURCE 
MANAGEMENT FOR THE MATRIX DECOMPOSITION MODULES 

Charles W. Bolz 
Computer Sciences Corporation 

SUMMARY 


Detailed computer resource measurements of the NASTRAN matrix decomposi- 
tion spill logic were made using a software input/output monitor. These 
measurements showed that, in general, job cost can be reduced by avoiding spill. 
The results indicated that job cost can be minimized by using dynamic memory 
management. A prototype memory management system is being implemented and 
evaluated for the CDC CYBER computer. 


INTRODUCTION 


The early large structural analysis programs were designed for second- 
generation computer systems that were severely core-limited, requiring struc- 
tural programmers to develop ingenious strategies for using mass storage to 
extend the range of solvable problems. It was for such a computer that NASTRAN 
was initially developed, and the matrix decomposition code with its efficient 
spill logic was a singular achievement in numerical analysis software. As 
NASTRAN was implemented on third generation computers which allowed multi- 
programming, such as the UNIVAC 1108 and the CDC 6000 series, it remained 
expedient to use as little central memory as possible in order to maximize over- 
all system efficiency. However, present day computers such as the CDC CYBER 175 
and the UNIVAC 1110 have very large, fast, low-cost semiconductor memories, and 
excessive mass storage usage can rapidly degrade overall system efficiency and 
increase job cost. It therefore becomes important for the user to select an 
optimum memory region size for his problem. 

In order to accurately assess the effects of memory region size on 1/0 
utilization and job cost, a software monitor was developed to measure 1/0 
volumes by file on CDC CYBER computers. Spill volume statistics were accumu- 
lated for the SDC0MP and CDC0MP matrix decomposition modules using NASTRAN 
Level 17.0.0 on the CDC CYBER 175 under the N0S 1.2 operating system. These 
statistics were interpreted using job cost accounting relations typical of CDC 
and UNIVAC systems. The results suggested that a dynamic memory management 
system designed to avoid spill would be cost effective, and a prototype system 
is being implemented on the CDC CYBER. 
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SPILL 


Matrices to be decomposed by NASTRAN are normally sparse banded matrices 
with relatively few terms away from the band. During the decomposition, it is 
desirable to have all the non-zero terms of a row, and all the non-zero terms 
of the triangular factor generated by reduction of that row, in main memory. 

If this is possible for each row, then the matrix need be read in from second- 
ary storage only once during the decomposition, and the factorized matrix 
written out. If insufficient memory is allocated, however, intermediate results 
muit be stored on spill files. Numerous passes through the spill files may be 
required to perform the decomposition. 

The matrix decomposition and spill logic is described in detail in refer- 
ences 1 and 2 . 


JOB COST ACCOUNTING ALGORITHMS 


The astute NASTRAN user interprets computer resource utilization guide- 
lines in terms of job cost, as assessed by his installation accounting algo- 
rithm. Results presented in this study are interpreted in terms of two 
accounting algorithms: one used commonly at CDC installations, and the second 

at UNIVAC sites. 

Many factors go into an accounting algorithm, but for NASTRAN execution 
only central memory used (CM), central processor-unit time (CPU), and mass 
storage input/output transfers (1/0) are important. In terms of these 
resources, the CDC accounting formula may be generalized as 


Cost = (1 + C-, CM) (C^ CPU + C 3 I/0)C^ 


and the UNIVAC relation as 


Cost = CM (Cj, CPU + C 3 I/0)C^ 

where Cg and C 2 are functions of the CPU and mass transfer device speeds. The 
constant C-j 1s set by the CDC N0S operating system at 0.007 per 512-word block. 
The dollar multiplier, C^, is installation dependent, so all matrix decomposi- 
tion costs presented in this study are normalized to the no-spill case. 

IBM accounting formulas vary with installation and operating system, so 
the IBM user should interpret the results presented in terms of his particular 
system. 





THE 1/0 MONITOR 


The basic utility for* this study is a software monitor which was originally 
developed by the author for analyzing the 1/0 usage of programs running under 
the CDC SC0PE operating system. The monitor decodes all 1/0 requests and 
records, by data block, the type of request and the number of physical records 
transferred between central memory and mass storage. The record is printed at 
the end of each module, as shown in Figure 1. 

As adapted for the CDC version of NASTRAN, the 1/0 monitor is called from 
XI0RTNS, which is the interface between GIN0 (General input/output) and the 
operating system (ref. 3). The monitor was validated by checking the total 
1/0 volume printed out against accounting log (dayfile) statistics for each 
NASTRAN run. Since the monitor itself occupies only 350 words of CYBER 175 
memory, and uses about 20 microseconds of central processor time per 1/0 
request, it has negligible impact on the job environment. 


THE COMPUTER RESOURCE UTILIZATION STUDY 


Complex Decomposition 


Two problems were chosen for study. The first is a complex eigenvalue 
analysis of a gas-filled, thin elastic cylinder (NASTRAN Demonstration Problem 
7-2-1 of reference 4). This case requires decomposition of an order 390 com- 
plex matrix, and can be solved by NASTRAN in a reasonable memory region only 
by using the determinant method. This particular problem was the impetus of 
the present study. When it was run on an IBM S/360-95 under the Multiple 
Variable Tasking (MVT) operating system with a memory region of 410000 bytes, 
an 1/0 timeout resulted after twenty minutes 1/0 time. When the region size 
was increased to 500000 bytes, the 1/0 time was less than five minutes. 

Computer resource requirements for this problem are shown in figure 2, and 
dramatically illustrate the effect of spill on resource utilization. As long 
as memory region size is small enough to require spill, 1/0 volume and CPU time 
are steep inverse functions of open core (scratch memory) size and job cost 
(as measured by the CDC accounting algorithm) is decreased by increasing core. 
But once sufficient open core is provided to avoid spill, CPU and 1/0 utiliza- 
tion remain constant, and job cost increases with increasing memory size. 


Real Symmetric Decomposition 


The second problem chosen is the static analysis of a long, narrow ortho- 
tropic plate, based on NASTRAN Demonstration Problem 1-4-1 of reference 4. 

This problem is useful for study because data can be readily generated for a 
broad range of grid sizes. Problem sizes ranging from 128 to 1100 active 
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columns were studied, (For a given memory region, spill is closely related to 
the number of active columns.) These were produced by grids of from 300 to 
2100 points, generating matrices of order 760 to 4990, respectively. 

A problem size of 277 average active columns, generated by a grid of 660 
points, resulting in a matrix of order 1660 was selected for detailed investi- 
gation. This problem has spill characteristics typical of large user problems 
commonly analyzed using NASTRAN. The grid is comparatively small; however for 
problems of similar spill behavior, CPU and 1/0 resource utilization are lin- 
early proportional to matrix order for a constant memory region. 

Results for this case are shown in figure 3 in non-dimensional form, nor- 
malized to the conditions at the open core size where spill is no longer re- 
quired. The outstanding feature of figure 3 is the 1/0 required by spill. At 
an open core size of 50% of that required for in-core reduction, 1/0 volume 
is seven times that required for in-core reduction. The CPU time curve illus- 
trates that, refined as the symmetric decomposition spill logic is, considerable 
computer time is used processing spill 1/0. And the cost curve shows that the 
cost penalty incurred by using more open core is more than compensated for by 
the reduced 1/0 and CPU resource requirements. 

To lend perspective, a cost curve was developed for a typical UNIVAC 1110 
system, where cost is directly proportional to memory used, and 1/0 is rela- 
tively less expensive. This curve is not as dramatic as the CDC curve, but 
still shows the importance of increasing open core to minimize spill. 


DYNAMIC MEMORY MANAGEMENT 


When matrix decomposition dominates a NASTRAN problem, the foregoing dis- 
cussion indicates that computer resource utilization can be minimized by 
requesting sufficient core to avoid spill, if possible. For typical problems, 
however, matrix decomposition is only part of the solution procedure. This is 
illustrated by the problem described in Table 1. The decomposition of the 
order 7000 matrix without spill would require a memory region of 160,000 deci- 
mal words on a CYBER 175, which is 30,000 words more than is available to a 
single program. But the decomposition step is only about 40% of the computa- 
tional effort. Another 50% of the computation can be performed in 50,000 words 
core, and the remainder in 70,000. 

This suggests that an ideal strategem to reduce computer costs would be to 
dynamically manage memory to give each module only the core it needs. Direct 
implementation of this idea would present a formidable task - 160 NASTRAN mod- 
ules to be modified. However, the results presented in Table 1 indicate that 
most of these modules - input, sort, geometry processing, element matrix assem- 
bler and generator, etc; require a small memory region, and suggest the 
following three-phase memory management scheme. 

(1) Execution of each module is attempted in a small memory region. 
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(2) Modules which can be expected to have large memory requirements 
compute and request the needed core. 

(3) Any other module which runs out of core while executing has its 
memory region expanded to a predetermined intermediate size. 


CDC IMPLEMENTATION OF DYNAMIC MEMORY MANAGEMENT 


The dynamic memory management scheme described above is being implemented 
on the CDC CYBER 175 as follows. 

(1) The user specifies to NASTRAN an initial and a nominal memory region 
size. 

(2) Before invoking each module, the link driver (XSEM) routine calls a 
subroutine MEMMGR (memory manager) to reset the memory region to its 
initial value. 

(3) The matrix decomposition routines call MEMMGR to obtain the open 
core needed to execute without spill. If insufficient memory exists, 
all available memory is obtained. 

(4) Modules that run out of open core normally issue an error abort call 
to subroutine MESAGE. This call is intercepted by MEMMGR, the nomi- 
nal memory region is assigned, and control returned to the calling 
module. (Note that this requires that the call to MESAGE be an in- 
line call). 

This scheme is being tested using the cases of figures 1 and 2 and Table 1. 
The predicted cost savings are shown in figure 2. These cases indicate that 
dynamic memory management to avoid spill can reduce job costs significantly. 


CONCLUSION 


An input/outout monitor was developed for the CDC version of NASTRAN which 
allows detailed analysis of computer resource utilization of the matrix decom- 
position modules. This analysis shows that for typical accounting algorithms, 
job costs can be reduced by avoiding spill in the decomposition. Analysis of a 
typical problem indicates that dynamic memory management could further reduce 
overall job cost. 
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TABLE 1 


THERMAL STABILITY STUDY 


Order of Matrix = 7215 
Average Active Columns = 238 
Maximum Active Columns = 505 
Three Spill Groups 


Operation 

CPU, seconds 

I/O, lO^PRU^^^ 

Memory Region 
(60 bit words) 

Input Processing 

49 

16 

52000 

Geometry Processing 

14 

20 

52000 

Element Matrix Processing 

140 

81 

52000 

Constraint Elimination 

183 

25 

52000 

Decomposition 

307 

157 

98000^^^ 

Static Solution Generation 

70 

81 

66000 

Totals 

736 

380 



(1) One PRU = Sixty-four 60 bit words 

(2) The decomposition would require 160000 words without spill 
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TABLE 2 


NASTRAN DYNAMIC MEMORY MANAGEMENT ON THE CYBER 175 
EXPECTED RESOURCE UTILIZATION AND COST SAVINGS 


Problem 

Memory Region 
(103 word) 

CPU 

(seconds) 

(103pRU)(l) 

Cost Savings 
(Percent) 

Demo Problem 7-2-1 

52 

45.3 

12.4 



74 

242.8 

49.2 

2.5% 

Demo Problem 1-4-1 

52 

49.6 

34.7 



94 

66.3 

26.9 

12.7% 

Thermal Stability Study 

52 

386 

142 



66 

70 

81 



98 ^ 2 ) 

307 

157 

14.3% 


(1) One PRU = sixty- four 60 bit words 

(2) The decomposition would require 160,000 words without spill 
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Figure 1. Output from the NASTRAN 1/0 Monitor (typical). 
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